       ********    **************************************************
             *    *                                                  *
            *     *                 The independent guide to BITNET  *
           *      *                                                  *
          *       *                                       May, 1988  *
         *        *                                                  *
        *         *                             Volume 2, Number 11  *
       ********   *                                                  *
                  *                                                  *
        ***       *                                                  *
       * * *      *                                                  *
       * * *      *                                                  *
       * * *      *                                                  *
       * **       *                                                  *
                  *                                                  *
           *      *                                                  *
           *      *                                            *     *
       ******     *                                           *      *
           *      *                                          *       *
           *      *                                     *****        *
                  *                                  **********      *
       ********   *                                *************     *
             *    *         ***                   ****** *******     *
            *     *       ******                 ********   *****    *
           *      *     ***   ** *******       ***********    ***    *
            *     *    *       ***************************           *
             *    *           *****************************          *
       ********   *          ******************************          *
                  *          *****************************           *
        ***       *           ****************************           *
       *   *      *            *******     *********  ****           *
       *   *      *             ****                    ***          *
       *   *      *             ***                       **         *
        ***       *             ***                       **         *
                  *              **                     ***          *
       ******     ****            **                                 *
           *      *******     ***************                  *******
           *      *****************************       ****************
           *      ****************************************************
       ****       ****************************************************
                  ****************************************************
           *      ****************************************************
           *      ****************************************************
       ******     ****************************************************
           *      ****************************************************
           *      ****************************************************
                  ****************************************************
       ********   ****************************************************
           *      ****************************************************
           *      ****************************************************
           *      ****************************************************
       ****        **************************************************
1

            *     *              *     *                   *
            **    *         *    **   **       *       *   *
            * *   *  ***  *****  * * * *  ***  ****  ***** ****
            *  *  * *   *   *    *  *  * *   * *   *   *   *   *
            *   * * *****   *    *     * *   * *   *   *   *   *
            *    ** *       *    *     * *   * *   *   *   *   *
            *     *  ****   *    *     *  ***  *   *   *   *   *
       *****                                                    ******


       Christopher Condon    Editor                  CONDON @ YALEVM
       Mike Patrick          Contributing Editor    PATRICK @ YALEVM
       Timothy Stephen       Contributing Editor    STEPHEN @ RPICICGE
       Craig White           Contributing Editor     CWHITE @ UA1VM
       Glen Overby           Technical Assistant   NU070156 @ NDSUVM1
       Gary Moss             Staff Supervisor          MOSS @ YALEVM


       ********************  Contents - Issue 21  ********************


       EDITORIAL PAGE_________________________________________________

       Bitnotes .................................................... 1
       The Human Factor ............................................ 2
       Flames To: .................................................. 6
       Let's bring BITNET to the Soviet Union ...................... 8
       HANET, Confusion, and Electronic Mail ...................... 10

       FEATURES_______________________________________________________

       Listserv 1.5n .............................................. 11
       TRICKLE and the SIMTEL20 Archives .......................... 14
       PCSERVER and the SIMTEL20 Archives ......................... 15
       The USENET / UUCP Network .................................. 16

       DEPARTMENTS____________________________________________________

       Headlines .................................................. 18
       Helpdesk ................................................... 19
       New Mailing Lists .......................................... 20
       Feedback ................................................... 25
       Policies ................................................... 26


       *  For information on  subscribing to  NetMonth,  submitting  *
       *  articles, sending  letters, and  printing this  file, see  *
       *  the "Policies" section on the last pages of this issue.    *


       -----------------------------------------

                A publication of the BITNET Services Library
1

                                                                Page 1


        *********
       *         *  Bitnotes
       *         *
       *         *  by Christopher Condon
       *         *
       *         *  CONDON@YALEVM
        *********


                            "Go ask your mother."


       I carry with me a certain sentimentality about BITNET.  This is
       largely  because  I  have   ventured  forth  (clean-shaven  and
       yuppified)   into the  world  of the  Fortune  100 and  learned
       something:  There is no experience out there quite like being a
       part of the BITNET community.

       Oh, I can impress people and figure out ways to send PROFS mail
       to friends at  other divisions of The  Corporation.   Otherwise
       all  of my  correspondence is  related  to business:    program
       problems, system specifications,  requests for assistance,  and
       so on.   All of it very fast, extremely useful, and exceedingly
       dull.

       Of  course we  all know  that  there are  very lively  computer
       networks that you can access when one is part  of the  Business
       World.   You can join mailing lists on any variety of business,
       research,  or entertainment topics.    What these conversations
       lack, however,  is that one topic which consumes so much of our
       thought, time, and  energy.   It is a topic unique our network,
       one to which on one else can lay a claim.

       The topic is BITNET itself.   I  doubt that the people in other
       networks have  ever devoted so  much correspondence  to talking
       about themselves as we.  Look, I am doing it right now, and you
       are reading  it.   People who  read about BITNET  reading about
       people who read about BITNET.

       Part of this, I believe, is our "frontier mentality".  Compared
       to other  networks BITNET is  young and disorganized.    I have
       always felt  that by actively  participating in the  affairs of
       the network that  I was part of some  great,  grand experiment.
       We have been on the frontier  of educational networking,  so to
       speak.

       BITNET is like our child.   We nurtured it's growth, watched it
       mature, suffered it's agonies,  and shared it's joys.   We have
       left imprints of ourselves on its  "personality" and the way in
1

                                                                Page 2


       which  people view  it.    At this  stage we  might  call it  a
       teenager;  showing hints of independence,  only now coming into
       it's own.

       It feels good to have been... to still be a part of that.  Just
       by being here we all become part of the miniature legacy of the
       Lifetime of BITNET.  We are the proud parents of our own little
       history,  a network that has grown larger and gone farther than
       we would  have ever  imagined.   There  is no  other experience
       quite like that.

                                Virtually,

                                         Chris Condon@YALEVM


        *********
       *         *  The Human Factor
       *         *
       *         *  by T. D. Stephen
       *         *
       *         *  STEPHEN@RPICICGE
        *********


       Comserve,  like other  file servers operating on  BITNET,  is a
       bonehead. It never tires, never complains, responds to anything
       that's sent to it, and never thinks for itself.  Naturally,  it
       is "aware" of certain things. For example, if mail arrives that
       contains either "Mailer"  or "Listserv" anywhere in  the return
       address,  Comserve  won't respond --  doing so might  create an
       endless exchange  of error  messages.   Avoiding  such "message
       wars" is very important, so in the interest of keeping Comserve
       out of trouble,   it has been programmed to  obey several rules
       about when not to respond to  messages.  In the final analysis,
       though,  Comserve and all of  the other automated communication
       systems on the net (e.g., Listserv,  Mailer,  Netserv,  Csnews,
       Nicserve,  etc.)   display only a tiny level of intelligence --
       they are all boneheads.

       As communication  systems,  a principal difference  between the
       boneheads and ourselves is in the way we process messages.  The
       boneheads are  literalists -- they  never distort  the messages
       they  receive;  they  react to  exactly what  was sent.   Human
       beings, by contrast, are richly interpretive, assigning meaning
       to a  message only  if we choose  to perceive  it in  the first
       place and only then after its full range of connotative nuances
       has been analyzed, after the message has been considered within
       the context of other messages we've processed (especially other
1


                                                                Page 3


       messages  received from  the sender  in  question),  and  after
       pondering any relational implications  the message might convey
       (for example,   does it  imply that we  are subordinate  to the
       sender or superior?  -- and how do we feel about this?).  Apart
       from any  formal procedures cooked  up by psychologists,   on a
       day-to-day basis, we often judge intelligence by the receiver's
       apparent level of sophistication in processing messages.

       Perception is  a cornerstone  in human  message processing  and
       I've long been fascinated by research  on how the human sensory
       system handles information.   Psychophysicists have constructed
       an ingenious  variety of  illustrations for  some of  the rules
       that govern how  we interpret sensory data.   For example,  the
       rule of proximity says that we tend to see things as "belonging
       together"  that   are  themselves  closer  together.    In  the
       illustration below, for example,  A is generally experienced as
       a series of columns while B tends to be experienced as a series
       of  rows.   Of  course,  boneheaded  computer  programs do  not
       "experience"  the world  at  all and  would treat  A  and B  as
       equivalent square matrices.




                  o    o    o    o    o          o o o o o
                  o    o    o    o    o
                  o    o    o    o    o          o o o o o
                  o    o    o    o    o
                  o    o    o    o    o          o o o o o    B

                            A                    o o o o o

                                                 o o o o o




       Perception researchers also talk about the role of "schemas" in
       our ability  to recognize patterns  and to reproduce  them from
       memory  later on.*  The idea  of the  schema  is that  it is  a
       "master form"  that helps us  to retain and  reproduce detailed
       information through reference to something familiar.  This idea
       is  illustrated  below.  The  dot  pattern  in  A may  be  more
       difficult  to remember  or  reproduce than  when  it is  turned
       upside down,   as in B,   and seen  to resemble the  Big Dipper
       constellation.

                        (figures on next page)
1

                                                                Page 4


                         _________________________________
                        ]                                 ]
                        ]                                 ]
                        ]                          o      ]
                        ]                   o             ]
                        ]                                 ]
                        ]                              o  ]
                   A    ]                                 ]
                        ]                   o             ]
                        ]                                 ]
                        ] o                               ]
                        ]         o                       ]
                        ]_________________________________]
                         _________________________________
                        ]                                 ]
                        ]                                 ]
                        ]                      o          ]
                        ]                              o  ]
                        ]                                 ]
                   B    ]            o                    ]
                        ]                                 ]
                        ] o                               ]
                        ]                                 ]
                        ]            o                    ]
                        ]     o                           ]
                        ]_________________________________]


       Perceptual schemas of the type  illustrated in this example are
       iconic,  retaining detailed information  through reference to a
       visual image of an actual object.  Human recognition and recall
       of  written  text  is non-iconic  and  is  facilitated  through
       familiarity derived  from past  experience.  For  example,  our
       facility in recognizing and reproducing a user's address in the
       "From:" line  of a  mail message  depends upon  past experience
       with the string of letters and numbers.  Obviously,  userids or
       node names that consist of  arbitrary collections are much more
       likely to be misread or  miscopied by respondents and therefore
       more  likely to  contribute to  a needless  profusion of  error
       message files and redundantly transmitted messages.

       As a  case in  point,  we've  found it  desirable to  provide a
       method of human contact for Comserve's users. Thus, we maintain
       a separate address to which users  can write and get answers to
       questions  about  the  service.   During   our  first  year  of
       operation,  that address was  Comsprt1@Rpicicge and,  though we
       didn't keep records,  I would guess that about one out of every
       20 mail files ended up in our system's dead letter office.  The
       most common  reason was  that the  sender had  misperceived the
1

                                                                Page 5


       numeral "1" as the letter "l" or,  less frequently,  the letter
       "o" as  the numeral "0".  Reasoning  that the problem  was that
       users  did  not   find  "Comsprt1"  familiar  or   sensible  --
       perceiving it to be an arbitrary collection of characters -- we
       changed our address to Support@Rpicicge. I would estimate that,
       in  result,   our  rate   of  misaddressed  correspondence  has
       decreased to 1 in 200 letters.

       There seems to  be quite a bit of variation  among BITNET sites
       in  their awareness  of this  principle,   or at  least in  the
       importance  that  they  attribute  to  it.   While  some  sites
       construct userids from the user's name, others appear to prefer
       arbitrary strings.  Node CALSTATE,   for example,  often issues
       userids of this  type:  PXXXXXX1 or JQQQQQ2  (quickly,  without
       counting,  how many X's  and Q's are in those IDs?).   A lot of
       other sites like to issue  more random userids (e.g.,  B1L46896
       or V90K113C).  It would also seem  to be the case that students
       are  issued the  difficult IDs  more frequently  than staff  or
       faculty.  The bonehead service  machines,  of course,  couldn't
       care less  about the organization  of the information  in these
       userids.   But  the  fact  is that  humans  will  have  greater
       difficulty with  them and misaddress their  correspondence more
       frequently when  they are  sending to  users with  addresses of
       this form.

       I'm not  sure why sites issue  such difficult userids  to their
       clientele,   but I  would  guess that  there  are probably  two
       contributing reasons: (a) that staff find it more convenient to
       do  so and  (b)   that difficult  userids  are considered  more
       secure.  Neither of these reasons is sufficiently compelling to
       warrant the inconvenience this practice generates.  With regard
       to keeping  it easy for  the staff,  I  would guess that  it is
       virtually as easy  to make a userid  generating program produce
       recognizable  userids  as  it  is to  make  one  that  produces
       unrecognizable ones.  As for the  security issue,  if it's true
       that  students are  more frequently  issued arbitrary  userids,
       then this is not an issue worth taking seriously; surely no one
       would assume  that students have a  greater need to  have their
       accounts protected than faculty or staff.

       As the networks  proliferate and their services  attract users,
       the  campus computer  center  will be  seen  increasingly as  a
       provider of  communication services.   This is  a new  role and
       brings with it a need  for new sensitivities,  sensitivities to
       the ways that people rather than machines communicate.  I think
       that  BITNET  can  be  made easier  for  people  by  increasing
       awareness of  some of the basic  differences that exist  in the
       ways that computers and humans process messages,  and by making
       it a cardinal rule that network addresses and computer software
1

                                                                Page 6


       systems be designed to be responsive to human biases in message
       processing.   Principles of perceptual  organization and memory
       can be  of value in  thinking about how  to make BITNET  a more
       humane environment and,  from a  technical perspective,  a more
       efficient and more smoothly operating network.

       *My source  for this discussion  is:  J.  E.   Hochberg (1978).
       Perception (2nd ed). Prentice-Hall.


        *********
       *         *  Flames To:
       *         *
       *         *  by Craig White
       *         *
       *         *  CWHITE@UA1VM
        *********


       This has  been a very busy  month for me.   The  semester ended
       with all of the assorted last  minute problems;  a new level of
       the operating  system being  installed and  faculty frantically
       trying to get work done before  the next semester starts.   And
       of course  there's all the mail.    I tried unsubscribing  to a
       couple of  lists and  using LDBASE  to keep  up with  the major
       topics.   Boy was I in for a surprise:   LDBASE cannot search a
       notebook if you are not currently on that list.  Oh well, maybe
       things will change at some point.

       This month's flame  has to do with the "You  are your brother's
       keeper" phrase.   At  least twice this month I  did not receive
       any mail for over three days.   At  least three times I did not
       receive any mail for at least two days.   A normal day will see
       many mail files making their way to my incoming box.  Normally,
       I do not use  network commands to find out about  the status of
       links on the network.   I can  usually tell when links are down
       because  of the  reduced flow  of mail  traffic.   This  month,
       however,  after two and a half days of the second three day dry
       spell, my curiosity got the best of me and I sent some commands
       to find  out how my  side of the  downed node looked.    When I
       looked  there were  over a  thousand  files queued  up to  pass
       through this node.

       I do not profess to be a  system guru or anything like that but
       it seems to me that when your link is down you would be working
       hard on getting  it back up.   If  this were to happen  at this
       site,  I  am certain that we  would work quickly to  remedy the
       situation  if for  no other  reason  than to  give the  network
       holding space a break, as disk space is at a premium here.
1

                                                                Page 7


       There is  a node near  us that  seems to go  down periodically.
       Either there aren't very many BITNET users there, or they don't
       care about people  down link from them.   What I  would like to
       propose in this Flames To:  is  that we each become responsible
       to our  fellow networker.    What I  mean is,   that if  a node
       adjacent to yours happens to go  down,  you should contact your
       BITNET technical  representative and have  them get  in contact
       with the representative at the downed node.   This way, even if
       the lead systems  programmer who knows all at  the downed sight
       is  away  for  one  reason  or  other,   maybe  your  technical
       representative can  offer suggestions  to the  operations staff
       regarding what could be done to get the network reconnected.

       I  realize that  a  lot of  people  might be  upset  at me  for
       suggesting that operators  use the advice given  by someone who
       has no  idea what  the local  situation is.    I think  that in
       today's environment (global communications)  this is not such a
       bad thing.   Furthermore,  I will go as  far as to say that the
       systems people  at adjacent  nodes should  periodically contact
       each other just to  shoot the breeze for a few  minutes and not
       just when problems occur.  I know of sites who have called over
       to their  next link  to inquire  about when  the link  would be
       reestablished and the systems people  didn't even know the link
       was down.   Granted this might be some kind of internal problem
       that the operations  staff didn't see the  problem and initiate
       the proper recover action, but the net (pardon the pun)  result
       was that  many nodes  where effectively  disconnected from  the
       rest of the world.

       Winding down,  I  have just been notified that  some links just
       came back up  by the 25 or  so files that just  popped up here.
       The Flames to me this month is for my tardiness in getting last
       month's Flames To:  to the publisher.   I'm sorry to all of you
       who had  to endure the  errors that I  didn't have a  chance to
       correct.   Provided the links are up,   this one should make it
       okay.  As always, questions, comments and flames should be sent
       to CWHITE@UA1VM.


                                       ************
                           ***************               ***
                   ********         ************

                                                **
                  *********               ***********
             *****************         *******************
          ************************* *************************** ***
        *************************************************************
       ***************************************************************
1


                                                                Page 8


        *********
       *         *  Let's Bring BITNET to the Soviet Union
       *         *
       *         *  by Jason Ohler
       *         *
       *         *  JFJBO@ALASKA
        *********


       Distance communication can be  roughly defined as communication
       in which  the sender  is in one  place and  the receiver  is in
       another, separated temporally,  spatially or both.   The gap in
       time and space is bridged by technology which we use to project
       three of our senses:  sight  (through data,  graphics,  video),
       sound (through audio),   and touch in a  limited sense (through
       the mail system).

       Yet, touch was the first sense to be projected at a distance in
       an organized, state-supported sense not through the mail system
       but via ballistics.    Ballistics is a crude  form of touching,
       essentially the extension of a  coiled fist sent raging through
       the air.   It is  a medium which has only one  message:  I hate
       you.   Ballistics is  different than the bow and  arrow and the
       spear in that enough distance  is introduced between sender and
       receiver   that   both  parties   become   faceless   entities.
       Unfortunately it has been the  only real distance communication
       medium between some parts of  the world,  particularly the east
       and west  as represented  by the  Soviet Union  and the  United
       States.  Until recently.

       The real  problem with a  ballistics communication  system,  in
       addition  to  its  obvious   destructive  tendencies,   is  its
       inability to carry detail.   For decades  the US and USSR,  and
       their allies,  have been living the  life of the morality play,
       where good  and evil  come to  blows in  a world  of black  and
       white, against a background of pure ignorance.

       Communications technology counteracts such ignorance.  With the
       addition of mail, audio, and video,  embedded in the context of
       glasnost,  citizens  of the US and  USSR have the  potential of
       experiencing   new,   more   detailed  and   varied  kinds   of
       communication.  Nameless entities become authors via electronic
       mail  memos,   conversationalists  via  phone  and  television.
       Enemies get fleshed out, take form,  and become human enough to
       invite  curiosity,   cooperation,   as  well  as  disagreement;
       anything but enmity.

       Fortunately with BITNET we are in the position of being able to
       do  more than  just talk  about  changing the  world.   I  have
1

                                                                Page 9


       experienced  the  power of  BITNET  at  work.   I  have  helped
       teachers establish networks  with students half way  around the
       world.   This Journal has helped many facilitate the sharing of
       ideas  and resources  in the  field of  distance education  and
       communication that  would otherwise be  too impractical  due to
       geographic  limitations,   time   differences,   and  financial
       constraints.   The routine  business that I,  and  thousands of
       others,  now conduct with colleagues  in countries all over the
       world via  BITNET is recreating us  in the image of  the global
       citizen.    In  short,   it  has  become  obvious  to  me  that
       international networking,  whether  among university colleagues
       or  seventh grade  science students,   politicians or  business
       people, is our best offense to counteract ballistics.

       LET'S BRING BITNET TO THE SOVIET UNION.   It will be a struggle
       to bridge  language barriers and  to work through  the hardware
       problems,  but it is certainly doable.    The last issue of the
       Journal contained an  article by a university  professor in the
       United   States  who   has  established   an  electronic   mail
       relationship  with colleagues  in  the  USSR.   The  Office  of
       Automated Systems in Moscow has  leased lines into Scandanavia,
       an area  that is  very active in  the BITNET,   EARN,  Netnorth
       network.

       LET'S BRING BITNET TO THE SOVIET  UNION.   And let's make it as
       easy as possible.   Let's send someone to the USSR to help them
       with the paperwork,  the logistics,   the hardware.   And let's
       invite the Soviets to our facilities as well.

       LET'S BRING  BITNET TO  THE SOVIET  UNION.   But  let's not  be
       naive.   To allow BITNET to become  the same kind of force that
       it has  become in the  west is asking  a lot from  a government
       that has presided  over an information constrained  culture for
       half a century.   But the Soviet Union is changing.   The worst
       that could happen is that they would say "no thank you."

       LET'S BRING BITNET TO THE SOVIET UNION.   More than likely,  we
       will make history.


                                       ************
                           ***************               ***
                   ********         ************

                                                **
                  *********               ***********
             *****************         *******************
          ************************* *************************** ***
       ***************************************************************
1

                                                               Page 10


        *********
       *         *  JANET, Confusion, and Electronic Mail
       *         *
       *         *  by Ake Olofsson
       *         *
       *         *  AAKE@SEUMDC51
        *********


       Occasionally  people  have  problems in  getting  through  with
       electronic mail to addresses in  the British JANET.  (Questions
       in  the  January,   1988 NetMonth  and  in  PSYCHNET  Vol2No38.
       Descriptions of  JANET and  its gateways  can be  found in  the
       JANET files  at NETSERV or NICSERVE  and in the  NetMonth issue
       mentioned above.)   In the  last year,   I have  helped several
       people in Sweden  having trouble in sending to  JANET.  In most
       cases the solution and explanation goes as follows:

       One of  the peculiar  things with JANET  is that  addresses are
       stated "the  other way  around" from  what is  the standard  in
       BITNET (and most other networks). Thus, a British user can have
       the local electronic mail address

       MAGGIE@OXFORD.VAX

       When this  fictitious user  wants to  give her  electronic mail
       address to a colleague abroad,  she asks her system manager for
       her complete address.   The manager may give her  two pieces of
       information:

       BITNET/EARN users must use a complete address, i.e.  specifying
       UK.   for  United Kingdom and  AC.  for the  academic computing
       network.  This probably sounds OK to Maggie;  she may have seen
       her address stated somewhere as MAGGIE@UK.AC.OX.VAX

       However,  BITNET/EARN users also must  write THE LAST PART (the
       part after  the @)  of the  address in a different  order.  The
       "real" address is MAGGIE@VAX.OXFORD.AC.UK

       What often seems  to go wrong is that the  reversal needed from
       least to  more specific  constituents is  carried out  only for
       part  of  the string  following  @.   For example  Maggie  will
       erroneously report  her address  to be  Maggie@oxford.vax.ac.uk
       instead  of MAGGIE@VAX.OXFORD.AC.UK  and the  BITNET user  will
       receive  a  reply  with  "undelivered  mail"  when  using  this
       address.

       Thus,  if  you don't  get through with  electronic mail  to UK,
       first  inspect the  address.   Is it  possible  that the  parts
1

                                                               Page 11


       following the @ are in the wrong order? Figure out which is the
       most specific one and should be  first,  which is the next most
       specific and  should be second,   etc.   When you  get through,
       suggest to  Maggie that it  would be  easier to join  the world
       rather than fight it.


        *********
       *         *  Listserv 1.5n
       *         *
       *         *  by Eric Thomas
       *         *
       *         *  ERIC@DEARN
        *********


       Starting with release 1.5n (which is  running on 100 servers as
       of today, 88/04/26),  a "global list registration" facility has
       been incorporated into the base  LISTSERV code.   It causes all
       the (1.5n)  LISTSERVs  to inform the "backbone"  servers of all
       the non-local lists they have, so that a global "list of lists"
       gets generated and automatically  maintained.   Along with this
       facility, "list location awareness" has been provided,  so that
       you can send  a SUBSCRIBE or SIGNOFF request for  just any list
       to any server (running 1.5n),  and it will take the appropriate
       steps to forward your request to the proper place.   Thus,  you
       don't  need to  worry  about  the node  on  which  the list  is
       defined.

       In  addition,    a  network-wide  unique  "List-ID"   has  been
       associated with each list,  to solve the problems of peers with
       different/conflicting names.   This "List-ID",  which acts as a
       (network-wide unique) synonym for the "real" list name,  may be
       up to 16 characters,  and makes  it easier to redistribute ARPA
       lists on EARN/BITNET.   For instance,   a list like "INFO-UNIX-
       STUFF" could be defined with a listname of I-UNIXST and a List-
       ID of INFO-UNIX-STUFF,  which would  make it possible for users
       to "SUBSCRIBE INFO-UNIX-STUFF" without  even knowing the actual
       list name.    You still have to  mail to the real  address,  of
       course.

       A new command, available from all the "backbone" servers (63 of
       them as of today), has been defined:

            LIST GLOBAL 

       This sends you  a 1-line description of each  known list.   You
       can specify  a search  string (as in  "LIST GLOBAL  /UNIX")  to
       select only a limited number of  entries.   This string will be
1

                                                               Page 12


       searched in the list name,  list-ID  and list title,  with case
       being ignored.   BE  CAREFUL:  there are over 920  lists in the
       database today,  and you'll get a lot of unwanted output if you
       do just "LIST GLOBAL".

       In addition, more extensive information is kept on some servers
       whose maintainers  have kindly volunteered to  provide adequate
       disk space  (some 2-3M).    This takes the  form of  a LISTSERV
       database called "LISTS",   which is presently available  on the
       following  nodes,  which  are all  "peers" as  far as  database
       management is concerned (ie there is no "master" server, and no
       server  has "more  accurate" information  than  the others,   a
       priori):

       FINHUTC   BNANDP11  HEARN  TCSVM  CEARN  MAINE  RUTVM1   MARIST
       DEARN  CANADA01  BYUADMIN  LEHIIBM1  UTDALVM1  UMRVMB  DBNGMD12

       This LISTS database  contains information about the  same lists
       that are  in the LIST GLOBAL  output,  that is,  all  the lists
       hosted by  a Revised LISTSERV  running version 1.5n  or better.
       Obviously,   ARPA or  CSNET-based lists  do  not appear  there,
       unless there is a LISTSERV redistribution on EARN/BITNET.   For
       each list,   the complete list header  is available and  can be
       searched using the standard LISTSERV database functions.   This
       also implies that you no longer  need to use the REVIEW command
       to get the description of a list.

       A  request  to access  the  LISTS  database  will fail  with  a
       "Database LISTS does  not exist" message if sent  to a pre-1.5n
       server.    When sent  to  a 1.5n  server which  is  not on  the
       backbone,  you  will be  provided with  the userid@node  of the
       backbone server nearest to the one you sent your request to.  A
       backbone server which  doesn't host the database  will give you
       the address of the nearest backbone server that does have it.

       If you are  not familiar with the  LISTSERV database functions,
       you  should  probably  read  "LISTDB MEMO"  first  (it  can  be
       obtained by sending an "INFO  DATABASE" command to any LISTSERV
       running 1.5m or better).   Please note that "INFO LISTDB" won't
       work (I know,  this was published in last month's article,  but
       then this article wasn't really from me.)

       The characteristics of the database are as follows:

       * DATE corresponds to the date the last update was GENERATED by
       the  remote server  hosting  the  list (remote  server's  local
       time).   Its resolution is the day,  ie 'yy/mm/dd' is available
       but time is  '??:??:??'.   Note that this  date is network-wide
       unique for a given list/update pair,  ie two servers which have
1

                                                               Page 13


       received the same  update for the same list will  bear the same
       date field regardless of their GMT offset.

       * LIST-ID (also LISTID or  ID)  corresponds to the network-wide
       "List-ID" keyword contents.

       * LISTNAME  (or NAME)  is  the actual name  of the list  (ie VM
       userid thereof).

       * NODEID  (or NODE)  is  the nodeid  of the server  hosting the
       list.

       * TITLE is the list title.

       All the keywords  defined in the various list  headers are also
       available, PROVIDED THAT THEY ARE NOT DEFAULTED.   That is, you
       can do "Select * in LISTS  where send=public and owner contains
       ERIC@FRECP11",   provided  that  the list  header  contains  an
       explicit definition for "Send" and "Owner".   If these keywords
       do not  appear in  the list header,   the default  values (resp
       "PUBLIC" and ) are NOT substituted.   This
       would require too much CPU time,  and in some cases the default
       value can be determined only by the server hosting the list.

       The following document "portions" are available:

       * ALL, Header or HEADER: the full list header.

       * ABStract or SUMmary:  all the lines in the header that do not
       contain  keyword definitions.    These  are  supposed to  be  a
       description of what the list is about.   In the worst case,  it
       will contain the list title.

       Finally, the default index looks like this:


       > Select * in LISTS where subscription=open and title contains mail
       --> Database LISTS, 3 hits.

       > Index
       Ref# Listname Nodename List title
       ---- -------- -------- ----------
       0027 MAIL-L   DEARN    Mail Discussion List
       0028 MAILBOOK DEARN    MAIL/MAILBOOK subscription list
       0054 XMAILER  DEARN    The Crosswell Mailer List


       A final note:   because of the number of separate  files in the
       database (one per list, ie around 1000),  searches that involve
1

                                                               Page 14


       looking  through the  whole  list header  take  a  lot of  time
       because of the file open overhead.  You should therefore try to
       avoid the "Search  XXX in LISTS" syntax,  and use  "Search * in
       LISTS where TITLE contains XXX and ..." whenever possible.   In
       most cases,   the list  title (which  is kept  in the  database
       index) will contain the words you are looking for.


        *********
       *         *  TRICKLE and the SIMTEL20 Archives
       *         *
       *         *  by Turgut Kalfaoglu
       *         *
       *         *  BILTUR@TREARN
        *********


       TRICKLE@TREARN  provides the  directory  listings and  recently
       requested files  from the  SIMTEL20 personal  computer software
       archives.   If the file that you  request exists in the TRICKLE
       directory,  then you  may expect to receive your  file within a
       few minutes.   If the file is not found,  the server will order
       it from LISTSERV@RPICICGE.   If this is the case,  the response
       time of TRICKLE is dependent upon the list server. TRICKLE will
       give up waiting for a file after five days after its request.

       The server will accept commands both by interactive message and
       in NOTE file format.   The command files may contain any number
       of instructions,  all  beginning at column one,   with a slash.
       The  commands are  similar to  the familiar  /PDGET and  /PDDIR
       commands  you may  have  used on  LISTSERV@RPICICGE.  For  more
       information send TRICKLE the /HELP command.

       The files  will mostly  be either in  Binary format,   in ASCII
       format, or in EBCDIC format. The binary files are recognized by
       the ".BIN",".EXE",  ".COM  ",  ".ARC",  ".LBR" suffix  in their
       names.  These files  are machine-specific (cannot be  used on a
       regular mainframe terminal). The files that are in ASCII format
       can be converted to EBCDIC (so that  they can be used on an IBM
       system)   by  running   a  program  called  ASCEBC.    If  your
       installation does not have this file, I can provide it.  Send a
       note to BILTUR@TREARN.

       We are also looking for a few good computer  centers that would
       be interested in running a copy of TRICKLE. When you run a copy
       of TRICKLE,  you  increase the power of the  whole file serving
       network. Since each TRICKLE is aware of each other's existence,
       they will inquire each other about the requested files, and the
       users will enjoy  a fast service,  if any  of the participating
1

                                                               Page 15


       TRICKLEs has that file. Since they inquire each other about the
       files in their caches,  there are  no multiple copies of a file
       on different TRICKLEs.  Your TRICKLE will automatically get its
       directories, (and sometimes its source code)  by its designated
       parent every couple of days.

         You will need:
         * VM/CMS 3.0
         * 10,3375 cylinders
         * Rexx Interpreter

       Please get  in touch  with BILTUR@TREARN if  you would  like to
       learn more about running a TRICKLE.

       *NOTE* Users in the United States,  Canada,  Japan,  and Mexico
       should not use this server.  LISTSERV@RPICICGE is your SIMTEL20
       server of choice.


        *********
       *         *  PCSERVER and the SIMTEL20 Archives
       *         *
       *         *  by Michel Daulie
       *         *
       *         *  DAULIE@BANUFS11
        *********


       PCSERVER@BANUFS11  provides access  to a  limited and  selected
       portion of the SIMTEL20 public  domain archives.   It should be
       considered  as a  measure  to relieve  some  of  the burden  on
       SIMTEL20 and RPICICGE from which  or through where the archives
       have been retrieved.

       The  archives available  on PCSERVER  are those  for which  the
       UFSIA academic  community has or  had the intention  to inquire
       into its possible use.   The local policy for downloading files
       determines what is available on the server.  This policy states
       that first of all 'human readable' files should be extracted to
       make possible  an evaluation  of the  needs the  software could
       cover.   This explains  why the greater part  of the collection
       consists of -catalog, readme and -doc files.

       Only interactive commands  are supported.   Do not  use mail to
       submit commands.   For  a list of commands,   send PCSERVER the
       command INFO.    Many of the  commands work  in a way  which is
       similar  to those  you  would use  to  access  the archives  on
       LISTSERV@RPICICGE.
1

                                                               Page 16


       The  PCSERVER userid  is the  master server  which will  accept
       commands  from the  users.    /PDDIR  and /PDGET  commands  are
       checked against the directory available on the PCSERVER userid.
       Whenever a match  is found PCSERVER knows  from the information
       contained in  the directory  which slave  server userid/machine
       has the  requested file.    The master  server will  store your
       requests untill the slave servers are online.  The slave server
       machines are IBM  3270 Personal Computers used by  the staff of
       the  UFSIA computing  center as  multisession terminals.    One
       terminal session  and the  PC session are  used to  support the
       slave  server functions.    PC session  and  slave server  will
       normally at least be activated once a day.  Higher availability
       may occur during the weekends.  The archives reside on the 3270
       PC hard disk  from where they are uploaded to  the slave server
       terminal  session  for  forwarding.    Interaction  between  PC
       session and terminal session are  by file transfer.   From this
       setup it  should be clear that  high performance should  not be
       expected and that availability can not always be guaranteed.

       Please   note   that   PCSERVER  is   EXPERIMENTAL   and   that
       modifications may be necessary.   Also we want to underline the
       fact that availability  of PCSERVER depends on  the performance
       requirements of our rather small installation.

       *NOTE* Users in the United States,  Canada,  Japan,  and Mexico
       should  not  use  this  server.     LISTSERV@RPICICGE  is  your
       SIMTEL20 server of choice.   Likewise, if you are on a European
       node which can only send commands to servers via mail, you must
       use the server TRICKLE@TREARN (see article in this issue).


        *********
       *         *  The USENET / UUCP Network
       *         *
       *         *  by Glen Overby
       *         *
       *         *  NU070156@NDSUVM1
        *********


       This article is fifth in a series about other networks.

       USENET is the Unix User's network, based upon the UUCP (Unix to
       Unix Copy)  file transfer system  distributed with Unix version
       7.   It is  commonly referred to as the UUCP  network after the
       transport protocol.   USENET came into  being in late 1979 when
       two Duke University grad students  in North Carolina thought of
       hooking  computers together  to exchange  information with  the
       Unix community.   There are now  about 11,000  nodes worldwide.
       USENET offers two major services: mail and news.
1

                                                               Page 17


       The USENET  news system  is a counterpart  to mailing  lists on
       other  networks,   with  a major  distinction  being  that  the
       postings are sent into a program  on each node,  where one copy
       is made available to all users.  The news system is independent
       of the mail system,  so the users  do not have large amounts of
       mail  from the  list  piling up  in  their  mailbox along  with
       private correspondence.   Since the users do not have to send a
       specific  subscribe /  unsubscribe message  to  a mailing  list
       maintainer, they are free to come and go as they please.   Many
       of the  more popular newsgroups  (about half  of the 300  or so
       existing groups) are gatewayed to mailing lists on the Internet
       and  BITNET.   More  recently,   other  networks have  starting
       picking up  the news  distribution system  because many  people
       find it much nicer than mailing lists.   As a result,  postings
       from these other networks are becoming quite common.

       Mail addresses on USENET are  given with explicit routing;  all
       machines in route must be explicitly stated.   For example,  to
       send mail from my Unix login at  NDSU to Yale,  I would use the
       address:

            uunet!antares!rutgers!harvard!yale!user's_login_name

       Explicit routing has  the obvious disadvantage that  users must
       know the entire path between two hosts.   To facilitate this, a
       "map"  of the  network has  been collected  and is  continually
       maintained by  a group  at Rutgers  University and  distributed
       monthly on the USENET  newsgroup comp.mail.maps.   Many mailers
       now have auto-routers which will figure the best UUCP path out,
       given an address in "user@node" format.

       Sending  mail to  USENET  sites from  BITNET  is frequently  an
       exercise in futility.    Some of this comes from  the nature of
       the UUCP links;   UUCP is a dial-up  store-and-forward network;
       when a call does not connect  within a few days,  many machines
       will "expire" mail and send a reject letter back to the sender.
       Other machines which are on larger networks, like BITNET or the
       Internet,  do  not have their  mailers configured  properly and
       will  frequently  trash  the sender  and  recipient  addresses.
       There is no administration on USENET to prevent this.

       The  official gateway  between USENET  and  BITNET is  PSUVAX1.
       PSUVAX1 has an auto-router which will  create the path for you.
       To send mail to my Unix login from BITNET I would use:

            NCOVERBY@NDSUVAX.UUCP
       or
            NCOVERBY%NDSUVAX@PSUVAX1
       or
            RUTGERS!UMN-CS!NDSUVAX!NCOVERBY@PSUVAX1
1

                                                               Page 18


       BITNET users can  find out from PSUVAX1 exactly  what path will
       be used with the RSCS-level  command "path".  For example (from
       CMS):

            SMSG RSCS CMD PSUVAX1 UUPATH NDSUVAX
       will return:
            ndsuvax rutgers!umn-cs!dicome!ndsuvax!%s

       This  example  is   also  an  example  in   the  difficulty  in
       automatically creating UUCP paths;   ndsuvax calls umn-cs three
       times per week, and dicome twice per month.


        *********
       *         *  Headlines
       *         *
       *         *  Smaller specks of news, but not unimportant.
       *         *
       *         *  send them to BITLIB@YALEVM
        *********


       * LISTSERV News:   The list servers at DEARN  and DBNGMD12 have
       been modified to act as name  servers using the /WHOIS command.
       The LOCSOFT  Filelist is  no longer  available at  EB0UB011 but
       will appear on DEARN in the coming weeks.   New list servers on
       the scene are LISTSERV@BINGVMB and LISTSERV@TREARN.

       * Marc Shannon has  set up a game server for  those of you with
       nothing better  to try.   LOTTERY@DRYCAS  is running  a special
       lottery-type game  available to all  BITNET users who  can send
       interactive messages.   LOTTERY allows users  to bet any number
       of points (up to their maximum, which starts at 2000)  and they
       can then win  in three different ways.    Anybody interested in
       finding  out  more   about  LOTTERY  can  send   a  message  to
       LOTTERY@DRYCAS with the command INFO.

       * For all of you in Turkey, there is a new NETSERV file server,
       NETSERV@TREARN.   It stores the same files and accepts the same
       commands as all the others, it's just closer to you.

       * UBSERVE@UBVMSC  has  been  moved  and renamed  VMSSERV@UBVMSD
       (note the  new node).    VMSSERV stores  software and  files of
       interest to people on Digital Equipment VAX systems running the
       VMS operating  system.   VMSSERV accepts  commands in  the same
       format as UBSERVE,  although there are some additions to permit
       the transfer of executable files.    Note that VMSSERV is still
       undergoing testing.
1

                                                               Page 19


        *********
       *         *  Helpdesk
       *         *
       *         *  a Question and Answer column
       *         *
       *         *  Send your questions to BITLIB@YALEVM.
        *********


       As  the questions  have  gotten more  and  more technical,   my
       inability  to answer  them  has  become increasingly  apparent.
       Thus,  this column  will be taken over by none  other than Marc
       Shannon, who has answered several of your questions in previous
       issues (and answers yet another one  here).  You can still send
       questions to  BITLIB@YALEVM and we  will forward them to one of
       Marc's many userids.  In the meantime...


       *Q*  Can  all nodes  on  BITNET  send and  receive  interactive
       messages?  If not, which can and cannot and why?

       *A*  Not all  BITNET  nodes can  send  and receive  interactive
       messages.   CDC  Cyber sites  and IBM  systems running  the TSO
       operating system are the first ones that come to mind, although
       there  may  be  others.    As  for  "Why",   these  are  simply
       limitations of their networking software.


       *Q* Why  is BITNET unable  to accept  mail  with lines  over 80
       characters long?

       *A* by  Marc Shannon:   This  is where the  different available
       file formats come into view.   The  basic two forms of files on
       IBM systems are PUNCH (fixed  length 80 character records)  and
       PRINT (fixed  length 132  character records).    There is  also
       NETDATA, CARD DUMP, DISK DUMP, VMSDUMP, and many others.  Since
       the goal  of sending mail  to someone is  that they be  able to
       read it,  the most common file  format is used for transmitting
       mail,  ie.  PUNCH.   Since you're sending 80 character records,
       you're stuck with that for your message.   This does,  however,
       vary from machine to machine.  Some MAILERs are intelligent and
       can wrap long lines while others may truncate them.


       *A* by John F. Chandler to last month's question, "Why is there
       a node OHSTMPA?"   A couple years ago there was  a Great Logjam
       -- thousands  of files  piled up  waiting for  transfer between
       PSUVM and  OHSTVMA.   Monthly routing  tables got stuck  in the
       traffic for  weeks;  even  small files took  days to  cross the
1

                                                               Page 20


       barrier;  file servers  all over BITNET were shut  down to help
       relieve  the congestion.    All this  came about  because of  a
       little incompatibility  between the RSCS  v.1.3 and  RSCS v.2.1
       line drivers at  the aforementioned respective hosts!    It was
       dreadful.    OHSTMPA  is the  solution  to  that problem  --  a
       "fictitious"  node  contained  within OHSTVMA  solely  for  the
       purpose of talking compatibility to PSUVM.


        *********
       *         *  New Mailing Lists
       *         *
       *         *  from List of Lists by Rich Zellich
       *         *
       *         *  ZELLICH@SRI-NIC.ARPA
        *********


       9370-L

       Discussion of  topics specific to the  IBM 9370 family  and the
       VM/IS packaging system,  and the special opportunities/problems
       of those products.

       To subscribe send  the following command to  LISTSERV@HEARN via
       mail or message: SUBSCRIBE 9370-L your_full_name

       Coordinator: Rob van Hoboken
                    


       AG-EXP-L

       Discusses the use of Expert  Systems in Agricultural production
       and  management.    Primary  emphasis   is  for  practitioners,
       Extension personnel  and Experiment Station researchers  in the
       land grant system.

       To subscribe send the following command to LISTSERV@NDSUVM1 via
       mail or message: SUBSCRIBE AG-EXP-L your_full_name

       Coordinator: Sandy Sprafka
                    


       IFIP-GTWY

       Mailing list for the IFIP 6.5  Task Group on Gateways (gateways
       and interworking  between X.400 and non-X.400  MHS environments
1

                                                               Page 21


       and   between  1984   and  1988   X.400  conformant   systems).
       Participation is open to anyone with something to contribute.

       All  requests  to  be  added to  or  deleted  from  this  list,
       problems, questions,   etc.,   should be  sent  to  <IFIP-GTWY-
       REQUEST@TIS.LLNL.GOV>.

       Task Group Chair: Tim Kehres
                         


       MEDIA-L

       Mailing list  for people in  the media services  profession who
       would  like  to  share  information   or  ask  questions  about
       educational communications and technology issues.

       To subscribe send the following command to LISTSERV@BINGVMA via
       mail or message: SUBSCRIBE MEDIA-L your_full_name

       Coordinator: Jim Blake
                    


       SEISM-L

       Seismological topics of general interest.

       To subscribe send the following command to LISTSERV@BINGVMA via
       mail or message: SUBSCRIBE SEISM-L your_full_name

       Coordinator: Jim Blake
                    


       SIMULATION

       All topics connected with simulation  are welcome;  some sample
       topics are:

            Real time simulation methods
            Flight simulation
            Parallel architectures for simulation analysis & modeling
            Simulation and training
            Distributed simulation
            Artificial intelligence and simulation
            Automatic generation and analysis of models
            Analog vs. digital methods, hybrids
            Continuous, discrete, and combined methods
1

                                                               Page 22


            Qualitative modeling
            Application specific questions
            Theory of simulation and systems
            Queries and comments about available simulation software
            Announcements of simulation-related talks and seminars
            Graphics and image processing in simulation

       All  requests  to  be  added to  or  deleted  from  this  list,
       problems, questions,   etc.,   should be  sent  to  SIMULATION-
       REQUEST@UFL.EDU.

       Moderator: Paul Fishwick
                  


       SOC-CULTURE-GREEK

       This  mailing  list  relays   the  soc.culture.greek  newsgroup
       (discussion of Greek  society and culture)  to/from  a group of
       subscribers,  that have NO USENET  ACCESS (people overseas,  on
       BITNET, on decnet,etc.).  Articles are collected and sent daily
       in a single mail message;  the headers of that message show how
       to subscribe and how to post something.

       All  requests  to  be  added to  or  deleted  from  this  list,
       problems, questions, etc., should be sent to SOC-CULTURE-GREEK-
       REQUEST@CS.WISC.EDU.

       Coordinator: Manolis Tsangaris
                    


       TECH-CONCEPTS

       Mailing list  based at  the Franklin  Institute discussing  the
       concepts of modern technology.   The purpose  of the list is to
       collect all of the concepts which the public should learn about
       in   dealing  with   computing,    robotics,   and   artificial
       intelligence in the coming years.  Any suggestions ranging from
       concepts to exhibits are welcome;   the Institute is opening up
       exhibits on energy,  space,  and health as well.   Comments and
       suggestions are welcome on all of these topics.

       All  requests  to  be  added to  or  deleted  from  this  list,
       problems, questions,  etc.,   should be sent  to TECH-CONCEPTS-
       REQUEST@FI.EDU.


       Coordinator: Brendan Reilly
                    
1

                                                               Page 23


       X-ADA

       This list discusses uses of the X Window System with ADA.

       All  requests  to  be  added to  or  deleted  from  this  list,
       problems, questions,    etc.,   should   be   sent  to   X-ADA-
       REQUEST@EXPO.LCS.MIT.EDU.


       XFONT

       This list discusses issues related to  using fonts within the X
       Window System (extensions, conventions, etc.).

       All  requests  to  be  added to  or  deleted  from  this  list,
       problems, questions,    etc.,   should   be   sent  to   XFONT-
       REQUEST@EXPO.LCS.MIT.EDU.


       XIMAGE

       This list discusses image processing with the X Window System.

       All  requests  to  be  added to  or  deleted  from  this  list,
       problems, questions,   etc.,    should  be   sent  to   XIMAGE-
       REQUEST@EXPO.LCS.MIT.EDU.


       XNONFB

       This list discusses implementing the  X Window System server on
       non-framebuffer graphics devices.

       All  requests  to  be  added to  or  deleted  from  this  list,
       problems, questions,   etc.,    should  be   sent  to   XNONFB-
       REQUEST@EXPO.LCS.MIT.EDU.


       XPC

       This list discusses implementing the  X Window System server on
       personal computers.

       All  requests  to  be  added to  or  deleted  from  this  list,
       problems, questions,    etc.,    should   be   sent   to   XPC-
       REQUEST@EXPO.LCS.MIT.EDU.
1

                                                               Page 24


       XPERT

       Mailing list  for general  discussion on  the X  window system,
       software running under X, and the like.

       All  requests  to  be  added to  or  deleted  from  this  list,
       problems, questions,    etc.,   should   be   sent  to   XPERT-
       REQUEST@ATHENA.MIT.EDU.


       XSERIAL

       This list discusses  implementing X Window System  servers that
       use serial lines as a communications link.

       All  requests  to  be  added to  or  deleted  from  this  list,
       problems, questions,   etc.,    should  be  sent   to  XSERIAL-
       REQUEST@EXPO.LCS.MIT.EDU.


       XTENSIONS

       This list discusses possible extensions to the X Window System.
       This is  a technical list and  participants are expected  to be
       fairly experienced with X.

       All  requests  to  be  added to  or  deleted  from  this  list,
       problems, questions,   etc.,   should  be  sent  to  XTENSIONS-
       REQUEST@ATHENA.MIT.EDU.


       XVIDEO

       This  list discusses  possible extensions  for  using live  and
       still video within the X Window System.

       All  requests  to  be  added to  or  deleted  from  this  list,
       problems, questions,   etc.,    should  be   sent  to   XVIDEO-
       REQUEST@EXPO.LCS.MIT.EDU.


       X11-3D

       This list discusses 3D extensions to the X Window System.

       All  requests  to  be  added to  or  deleted  from  this  list,
       problems, questions,   etc.,    should  be   sent  to   X11-3D-
       REQUEST@ATHENA.MIT.EDU.
1

                                                               Page 25


        *********
       *         *  Feedback
       *         *
       *         *  a Letters column
       *         *
       *         *  Send your letters to BITLIB@YALEVM
        *********


       From:     Stephen McCluskey
       Subject:  Unanswered mail / mail forwarding

       I  presume  you've  been  following  the  Chronicle  of  Higher
       Education's discussion of networking.  Robert Blystone's letter
       in the  4 May  issue touched  on one  of the  crucial problems:
       people not answering their mail.

       As presently configured at our  institution,  and as Blystone's
       letter suggests at  most everyone else's,  the only  way to get
       BITNET mail  is to  log on to  a mainframe  computer regularly.
       Except  for  those  who  use   mainframes  regularly  in  their
       research,  those  with research  assistants,  technicians,   or
       secretaries to  do such  drudge work,   and committed  computer
       junkies,  BITNET messages  can go unnoticed and  unanswered for
       weeks or months.    For most academics who don't  want to waste
       ten minutes a day (and several hundred dollars in computer time
       a  year)   to  check  for an  occasional  message,   BITNET  is
       substantially slower than the postal system.

       I suspect this is the chief reason why BITNET,  its discussions
       and  List Servers,   remain largely  the  preserve of  computer
       types, people who use computers in their research and teaching,
       and those  interested in the  study of communications.    If we
       compared BITNET to that other shared academic institution,  the
       library,  it's like  a library in which most of  the books deal
       with bibliography and libraries.

       One feature that could open BITNET to the infrequent user would
       be  programs  for  the various  mainframe  systems  that  would
       periodically (daily ?)  scan a user's reader for incoming files
       and  dump  a  printed  notice  or a  hard  copy  in  the  local
       interoffice  mail system.    Probably  the greatest  difficulty
       would be getting  a computer center's POSTMASTER  to become one
       in the literal sense  of the word,  but if we  are committed to
       BITNET  as a general purpose academic  network,  some  outreach
       beyond the computing community is vital.

       Since so  much of BITNET runs  on volunteers are there  any out
       there who know of such systems?   Is anyone able and willing to
       develop them?
1

                                                               Page 26


        *********
       *         *  NetMonth Policies
       *         *
       *         *  Everything you ever wanted to know...
       *         *
       *         *  BITLIB@YALEVM
        *********


       NetMonth is a  network service publication distributed free  of
       charge to  students  and  professionals  in  BITNET  and  other
       networks. This magazine and its companion file, BITNET SERVERS,
       are the  work  of the  BITNET Services Library (BSL) staff  and
       contributors from around the network.

       BITNET SERVERS is BITNETs list of servers and services.  If you
       know of servers not listed in BITNET SERVERS, or if some listed
       are no longer available, please contact the NetMonth Editor.

       * Subscribing to NetMonth and BITNET SERVERS:

       Send  the  following  command  to  LISTSERV@MARIST  by  mail or
       messgage:

            SUBSCRIBE NETMONTH Your_full_name

       Internet users may use this method, but must  address  the mail
       to LISTSERV%MARIST.BITNET

       * Back issues:

       BITNET users  may get NetMonth back issues from the file server
       NICSERVE@BITNIC.

       A subscriber  can delete  him/herself from  the mailing list by
       sending LISTSERV@MARIST the UNSUBSCRIBE NETMONTH command.

       * Letters to the Editor:  If  you  have  questions  or comments
       about BITNET or  NetMonth that you would like  to  see  printed
       here, mail  your letter  to BITLIB@YALEVM.  Make  sure that you
       specify in the "Subject:"  header or  somewhere  in  the letter
       that it is for the NetMonth letters column.

       * Article Submissions:  The  only  requirements  for   NetMonth
       articles and columns are that they be informative, interesting,
       and concern some BITNET-related topic.  Send your articles  and
       to BITLIB@YALEVM.
1

                                                               Page 27


       * Printing this file:  VM  users can print  this file  by first
       copying it to NETMONTH LISTING and then printing  the new file.
       This will allow page-breaks and other formatting to be accepted
       by your printer.


            _
           __-
          __---    The
         __-----   BITNET
        __-------  Services
       ___________ Library                       "Because We're Here."

       ***************************************************************